State diagrams are commonly used to define the operations of real-time processes. When a computer system that is executing a language, such as C or Pascal, is being used to control the operations of the real-time process, the program has one set of instructions for each of the possible states and the signals that can be received in those states. While in a given state, the instructions are sequentially executed upon the receipt of individual signals to perform the required control functions. The computer's response to process signals is implicit from the sequence of instructions.
There are languages wherein the states and process signals are explicitly defined, and in which the occurrence of these states and signals causes the execution of specific action instructions. One such language is described in the article by J. M. Ginsparg and R. D. Gorden, "Automatic Programming of Communication Software Via Non-Procedural Description", IEEE Transactions on Communications, Vol. COM-30, No. 6, June, 1982. This article discloses a programming language for writing programs to control a telephone switching system. Such programs are written in terms of the possible states of the system, occurrences of events within the system, and actions to be taken when defined events and states occur. After program statements are written in that language, they are then translated to the C programming language and compiled and stored within the computer controlling the telephone switching system. Whereas, this language does allow the statements to explicitly designate the actions to be taken in response to a given event, no provision is made for performing common actions that are required upon entering or leaving a state, regardless of individual state transitions. Without provision for performance of such common actions, the resulting programs become complex and difficult to modify.
Another approach is the Specification and Description Language, SDL, that is currently being defined by a CCITT committee. The SDL language is described in the article, "SDL-CCITT Specification and Description Language," IEEE Transactions on Communications," Vol. Com-30, No. 6, June, 1982, by A. Rockstrom and R. Saracco, and the CCITT specifications are set forth in Recommendations Z101-104, CCITT Yellow Book, International Telecommunication Union, Geneva, Switzerland, 1981. The SDL language allows a formal description of services and features in terms of state and telecommunication signal information. Manufacturers of telecommunication systems then implement that formal description in the language of their choice, such as CHILL or C. The SDL description itself is not directly compiled. In addition, SDL does not provide for the execution of common actions upon entering or leaving a state.
As previously noted, a problem common to both of the previously mentioned prior art methods of utilizing state diagrams in real-time process control is the performance of actions that must commonly be done upon leaving a state and entering a new state, regardless of the particular transition involved, (i.e., the event that motivated the transition). An example of such an action occurs in a telephone system where a customer's telephone is being rung, e.g., it is in the ringing state, and the customer goes off-hook, e.g., an off-hook signal is received. The required actions are to remove the audible ringing indication from the customer's telephone, and upon entering the next state, e.g., talk state, to establish a voice connection to the calling telephone.
In simple telephone service, often referred to as plain old telephone service (POTS), the problem is reasonably easy to solve since the possible ways of going from the ringing state to the talking state are well known at the time of programming POTS service. Problems arise at a future time when it is desired to add new telephone features that will interact with POTS in unforeseen ways. In the prior art programming techniques, the programmer writing such new features needs to fully understand the original code and the interaction of his or her new code with the original code in order to determine all of the ways under which a state could be entered or left. This requirement not only delays the introduction of new features, but makes maintenance of existing programs more difficult.
From the foregoing, it can be seen that there exists a need for a software mechanism that will assure that certain specified actions are taken each time a new state is entered and each time a state is left regardless of the circumstances under which those events occur. Such a mechanism would perform the required operations upon entering the state and the required operations upon leaving the state. In addition, the execution of these required operations should require no additional program statements in any new features being added or even the programmer's knowledge of how these operations are performed. Yet, the programmer should have the ability to modify and add to these operations.